Skip to main content

第22章 数据湖

第22章 数据湖​

一、概述​

  • 华为的openGauss不是云数据库，搬上云GaussDB才是云数据库。
  • openGauss是一个高性能、高安全、高可靠性的企业级开源关系型数据库
  • openGauss是一个单进程多线程的架构，但是mySQL是一个多进程的架构，很可能一个数据库连接就对应一个进程。使用单进程的话可以降低通信的开销。多进行需要使用到进程间通讯，而单进程的话可以使用共享内存的方法。
  • 单表大小32TB，单行数据量支持1GB

二、行存储和列存储​

  • 行存储：适合业务数据的频繁更新，比如插入更新一条数据，类比双十一开卖的时候订单很多条目要插入进来
  • 列存储：支持业务数据的追加和分析场景，类比双十一结束的的时候需要统计销售额【注意：在批量加载的时候为什么更适合列存储呢？因为列存储的时候压缩率高，比如某一列连续下来存的是5个连续的1，我就可以压缩一下，或者我时间戳的话发现可以记录一个增量，这样就大大的优化了存储的空间，使用列存储的话更加的高效】
  • openGauss的引擎会根据执行的SQL语句判断是在行还是列存储上进行查找
  • 同时做行存储和列存储的缺点是浪费了空间，但是好处是适合的SQL会发到对应的存储上，速度会明显提高。
  • 内存表：数据整个在内存里面，大量的数据一次性加载到内存里面，以后的所有操作全部都在内存里面，可能只要我不关机，我可能数据一直都不用落硬盘，每天可能为了备份，把数据落一次硬盘。（那和我们之前说的mysql有什么区别呢？之前所说的buffer比较小，我们只能把正在操作或需要操作的数据加载到buffer里面，但是内存表要求很大大的缓存，开机的一刻就把数据加载到内存中）
  • 应用场景：比如存储一系列风力发电机的厂家、型号、风场信息用行存储，但是如果风力发电机不断的发时序数据的话，这些数据应该更适合列存储。同时需要行、列存储的场景就是这样

三、ORM效率​

有人可能有疑问：ORM映射是通过把对象的操作通过JPA工具生成SQL语句，然后发送给数据库进行操作的，那如果我自己直接写SQL语句的话不是避免了这个转换的过程，一定会有更高的效率吗？

回答：错误的。JPA工具里面有大量积累的优化的SQL的经验，会把对象的操作转换为基本上说是最优效率的SQL操作语句。但是如果你自己写SQL语句可能效率远远比不上。但是有人说数据库不是有查询优化吗？实际上数据库的查询优化很有限（课上的举例就是底板不行怎么打扮都不好看）所以说通过ORM映射产生的SQL基本就是最优解。此外还有一种情况，比如数据库里面有一些函数需要被调用，他们产生的是一个结果返回我，数据的处理就是在数据库里面实现的，如果用ORM的话可能会写一个遍历，那这样的情况可能ORM就比较差。

四、数据仓库​

  • 多元的数据如何融合处理？数据仓库：把很多来源的数据加载之后，把他们安装同一个方式存储。

  • 比如交大的数据、复旦、同济的数据，可能分别有10、11、12个字段的数据，需要把这些数据”抽取、转换

    存储“，通常来说把不同的文件转存储到Parquet/RC File的文件格式

  • RC File的文件：把原始的关系抽取某一列或者几列、甚至把整个表存储起来。同时文件最前面还有有一些元数据表达的行号是哪几行、或者是否有压缩，压缩后key长度。然后这些文件被建成HDFS的块。

  • Parquet：类似RC File。

  • 存在的问题：需要ETL（抽取、转换、存储）然后写入到Parquet的中间文件格式，这个的代价是很大的。而这些文件在之后如果直接做SQL的时候效率很低。所以最终还是要转到SQL的数据库中（直接对数据库处理）那我们就想：如果数据来了，我们可不可以先把数据按照原始的格式存储，当我真正需要的时候，再把数据导入进来。所以这就是数据湖

五、数据湖​

  • 在湖里面存储的是标准的数据，就是当数据来了之后保持的原始的格式存储的
  • 在必要的时候会通过ETL的方法，把数据导入到数据仓库的里面
  • 数据湖要解决的问题就是：面临大量的数据要导入的时候怎么把原始数据快速接受下来
特点数据仓库数据湖
数据关系数据各种数据（因为它是直接存储的原始数据：结构化半结构化等等都可以）
schema模式比较严格的模式，数据在读取的时候或者写入的时候做一个校验（schema-on-write或者read）schema-on-read（只有在数据分析的时候，也就是从读走数据的时候校验数据的模式是否合法，因为它是直接存储的原始数据，存储的时候不校验）
性能本地存储的时候非常快用低成本的存储把大量的数据存储进来，当搜索的时候可能比较慢
数据质量schema-on-write，过滤了不合规定的数据因为所有数据直接接受，质量无保证
用户：数据科学家、数据开发者，对数据查询要求比较多，质量要求比较高用大量数据，对错误的容纳程度高一些
分析领域商业智能、可视化机器学习、等哪怕数据有偏差不会影响最后大局
  • 湖仓一体：不管是谁要来查数据，都到底层去抓数据，如果是关系型的就去关系型的找数据，非关系型的就到非关系型的去找就好了，不严格区分数据湖和数据仓库。